Use the secretOrKeyProvider option in PassportStrategy to perform a dynamic secret lookup. Decode the token without verifying it to extract the tenantId, look up the tenant's secret, and return it to Passport for signature verification. This is safe because the secret is used for verification, not trust.
Decoding without verifying to read tenantId is safe — the payload is only used to look up the verification secret.
The signature is verified by Passport after secretOrKeyProvider returns the correct secret.
validate() confirms the user belongs to the tenant in the token — prevents cross-tenant token reuse.
Use a different signing key per tenant — a compromised tenant's secret does not affect other tenants.
Cache tenant secrets with a short TTL to avoid a database lookup on every request.
We have a NestJS microservice that needs to issue JWTs for two tenants, each with its own secret. How would you set up the AuthModule to load the correct secret based on the incoming request?
If a request includes a tenant identifier in a custom header, what steps would you take to verify the JWT using that tenant's secret?
You added a dynamic JWT secret per tenant, but after deployment some tokens are being rejected for a specific tenant. Walk me through how you'd debug the issue.
Explain the trade‑offs between storing tenant secrets in environment variables versus a database when implementing per‑tenant JWT validation in NestJS.
At scale we have thousands of tenants and need to validate JWTs efficiently. How would you design the secret‑lookup mechanism to avoid performance bottlenecks and keep the AuthGuard stateless?
Consider a scenario where a tenant rotates its secret while users still have active tokens signed with the old secret. How would you handle secret rotation without breaking existing sessions?
Our platform is moving from a single‑tenant JWT secret to a multi‑tenant model across multiple services. What architectural changes would you propose to keep authentication consistent and maintainable across teams?
Discuss the long‑term security and operational implications of storing per‑tenant JWT secrets in a centralized secret manager versus embedding them in each service's config.